After completing this lesson, you'll be able to:
Checking the feature type properties for a dynamic translation reveals the checkboxes that turn on this behavior.
For a reader, all that is required is to check Merge Feature Type:
Unchecking that box turns off the entire behavior, and there are not many parameters to adjust. You can change the Merge Filter to control which feature types FME reads (see the list of wildcards here), but that's about it.
However, for a writer, the dialog is a bit more complex:
You can set the three components of schema - 1) feature type, 2) attributes, and 3) geometry - in different ways.
There are three main components of a schema:
This lesson examines feature types and how a workspace author can change the feature types written in a dynamic translation.
Defining Feature Type Names
In static writer feature types, the feature type name is usually a fixed value. However, you can also define it using an attribute (or string constructed from attributes). We call that a fanout.
See Read From and Write To Multiple Locations to learn more about fanouts.
Dynamic translations use fanouts automatically. By default, the writer feature type uses an FME attribute called fme_feature_type as the feature type name:
fme_feature_type is an FME attribute that stores the name of the original feature type on incoming features. Using this attribute for the feature type name means FME will re-create the source feature types in the destination data.
However, should you wish, there's no reason why you can't use a different attribute to define a different set of output feature types:
For example, the author above uses NeighborhoodName to supply the name of the layers to create. Features might have the value Downtown, West End, or Fairview.
FME looks in each Schema Source at runtime to find a Downtown table. It will use the schema of that table to define the attributes and geometry allowed in the dynamic writer's output.
Schema Requirements
Dynamic writer feature type definition isn't the same as a fanout. A fanout creates layers from a static definition. A dynamic workspace fetches that definition from somewhere else (the schema source). Therefore, the feature type names must match a layer in that source schema.
Failure to do so will lead to FME dropping the data, i.e., not writing it, and creating a log message reporting the problem. For example, if the NeighborhoodName attribute had values (like "Downtown" or "Kitsilano") that didn't exist as a table in the schema source, the log would look like this:
FileGDB Writer: A feature with feature type `Downtown' could not be written FileGDB Writer: A feature with feature type `Kitsilano' could not be written
The author must ensure that the schema used contains these layers. Then, the translation will proceed as expected.
By default, the writer schema in a dynamic translation is defined not in the workspace but by the source dataset. So, whatever dataset you choose as input defines the chosen output structure.
However, the parameters in a writer feature type let us alter how that schema is defined. We can take the structure from an entirely different dataset to the source. Alternatively, we can individually define each component of our schema (Feature Types, Attributes, Geometry) in various ways.
The writer feature type has a dynamic parameter labeled Schema Sources:
This parameter defines where the writer will obtain the destination schema. By default, this parameter uses a source dataset. That way, the output schema always duplicates the input.
However, you can set it to use any reader dataset – in any format – as the source for the outgoing schema.
For example, this workspace author is converting parks data to an Esri Geodatabase but has chosen an Excel spreadsheet as the required structure for the output dataset.
If the data is fanned out (say by NeighborhoodName), then the Excel spreadsheet should have a different sheet for each neighborhood, and the output in this workspace uses that structure as the schema.
Let me make it clear if it isn't already. In this scenario, the user is not writing to those Excel sheets but to a File Geodatabase. However, the output Geodatabase receives the same schema (structure) as the matching Excel sheets.
It's called "Dynamic" because the destination schema gets fetched at runtime. For example, if the Excel sheets were to change in structure and the workspace ran a second time, it would produce Geodatabase feature types to match the changes. The best part is that the workspace does not need updating to do so.
Resource Readers
You can set the Schema Source parameter to point to any reader as the source of a dynamic schema. However, in most cases, all we need from the dataset is the schema, not the data.
You can use Resource Readers when you only need the schema of a dataset.
A Resource Reader is a reader that returns the schema of a dataset but no data. You can add one using Readers > Add Reader as Resource on the menu bar:
Here, the user adds an Excel spreadsheet database as a resource, and it appears in the Navigator window:
Once available, you can use the resource reader as a schema source for a dynamic writer.
Why Use an External Schema?
The main reason for using an external dataset schema is to adhere to a fixed standard. Perhaps the most beneficial aspect is that if the dataset's schema changes, the workspace automatically uses it. You don't need to update the workspace manually because the output requirements have changed.
However, as noted above, the written data must match that standard, or the writer may drop it. So, data transformation is likely required in the workspace to coax the input data into the required output schema.
The SchemaMapper transformer helps reconcile data with the required schema. It can also use an external lookup table, meaning you can change the dynamic workspace to meet any required output schema without having to edit in Workbench!
We will discuss geometry shortly. However, for now, be aware that permitted geometry types are (by default) obtained from the schema source. If the schema source changes, you may not want its geometry type.
Therefore, set Geometry to "First Feature Defines Geometry Type" to avoid issues.
